Azure Container Registry Best Practices 

Follow these best practices to ensure your Azure Container Registry is secure, efficient, and well-managed.

Tip 1: Disable the Admin Account on Your Container Registry

There is a likelihood that the Dev team keeps the admin account enabled. In production, mitigate this by disabling the admin account and enabling RBAC and Azure AD authorization instead. Use managed identities, service principals, or users—anything that suits your architecture and infrastructure but is more traceable in the end.

  • Option 1: Disable ACR Admin User from the Azure Portal

    From the Azure Portal, navigate to your Container Registry and select "Access Keys." Disable the admin user from here.

  • Option 2: Disable ACR Admin User from Azure CLI

    Use the Azure CLI to disable the admin user:

    Copy 
    az acr update -n myacr --admin-enabled false

  • Option 3: Disable ACR Admin User from Azure PowerShell

    From Azure PowerShell, you can also disable the admin user:

    Copy 
    Update-AzContainerRegistry -Name 'myacr' -ResourceGroupName 'rg-weu-myacr' -DisableAdminUser
     

Tip 2: Authorization

  • Using Service Principals

    Key reasons for usage:

    • Ideal for services and apps running automated tasks without any interactive authorization flows.

    • Provides granular access rights instead of a "one key to rule them all."

    • Supports read-only scenarios where the principal can never modify or push images.

    For more information, refer to the documentation: [Azure Container Registry authentication with service principals].

  • Using Managed Identity

    Key reasons for usage:

    • Offers granular access control with RBAC.

    • Enables specific services or resources to have direct access to what they need, enabling granular access controls for various services with different identities, like "This Azure Container Instance should have Reader access only."

    • The identity tied to a given resource can also be assigned permissions to other resources that support managed identities, providing an easy way to manage access for that one resource without creating additional principals.

  • Tokens and Scope Maps

    • Time-limited access to help block any access after a specific point in time.

    • Granular permission control to restrict or allow specific actions on the registry, such as Read (pull), Write (push), and Delete.

    • Helps delegate permissions more easily, allowing consumers of images to have read access to the repository they need (only pull the images and not update or change anything).

Token and scope maps-based approach for Azure Container Registry introduces great repository-level access restrictions:

For more information, refer to the documentation: [Tokens and Scope Maps for Azure Container Registry].

Tip 3: Role-Based Access Control (RBAC)

Strict access rules must be defined using RBAC in the Azure Container Registry.

  • Practices:

    • Assign the 'Reader' role to identities/users/principals who should only pull images, but never modify or make other changes.

    • Stay on top of your RBAC assignments and ensure there's no delegated access and no inherited access for certain accounts with many privileges.

    For more information, refer to the documentation: [Azure Container Registry roles and permissions].

Tip 4: Enable Azure Security Center

Azure Security Center reports on container flaws in an Azure Container Registry. With Security Center, the registries can be automatically scanned, which is very helpful. Clicking one of the items provides a detailed explanation and links, including the public CVEs.

The detail’s pane gives comprehensive insights into the security vulnerabilities found in the registry. This information can help decide whether to act or not. Ideally, when there's any type of security flaw, it is best to remediate it as soon as possible.

Tip 5: Use Content Trust

Docker comes with a model called "Content Trust," which enforces signing images that are pushed and pulled. With content trust, the idea is to verify the source and integrity of the images, ensuring that they are the images we expect. The images can be signed as they are pushed into the registry and then be configured so that the clients can only pull signed images from a trusted source with verified data integrity.

For more information, refer to: [Content trust in Azure Container Registry].

Tip 6: Build New Container Images as Base Images Are Updated

If container images are generated from any available base image, there is a high chance that these images will be updated at some point. For example, if you are running .NET Core-capable Docker images, Microsoft has its base images [here].

With the Azure Container Registry, you get something called "Tasks" that can help automate this process—it supports automated build execution when the base image is updated.

For more information, refer to: [Automate container image builds].

Tip 7: Store Sensitive Configuration Data in Azure Key Vault

Azure Container Registries are usually configured with IAM and accessed using Service Principals. This allows for granular control with RBAC. Services that connect to ACR often store the credentials to this said Service Principal in plain text or other non-protected resources like application configuration (app.config, project.json, etc.) or simply in Environment Variables (Configuration on an Azure App Service / Function App, etc.).

This can be mitigated by making use of an Azure Key Vault. The service/app/daemon uses Managed Identity to access the Key Vault, reads the Service Principal credentials from the secrets in the vault, and uses these credentials to access the ACR. By putting sensitive data inside Azure Key Vault, the credentials at rest are protected as well, which isn't the case if it goes into a configuration repository that isn't inherently secured for sensitive data.

Tip 8: Review Activity Logs for Your Container Registry

Azure Container Registry audit logs can be viewed in the "Activity log" menu option on the Azure Portal. Reviewing these logs regularly helps to stay on top of things, explore, and find any erroneous, suspicious, or anomalous activity.

Tip 9: Use the Firewall

With a virtual network or firewall rule in place, the traffic flow can be controlled more easily. Use and enforce this setup wherever applicable when using ACR.

For more information, refer to:

Tip 10 (Preview): Repository-Scoped Permissions

Instead of scoping RBAC at the entire ACR level, permissions can be scoped directly to a repository inside the ACR. This enables more granular control of access, enabling a single ACR for a use case with multiple images, where different access control is required. An identity with Reader access can only read from a given repository instead of the entire registry and all repositories inside it.

Known limitations (as of 2020-02-07 Preview):

  • Access cannot be assigned to an Azure AD object like a Service Principal or Managed Identity.

  • This is only available in the Premium tier of ACR.

For more information, refer to[Repository-scoped permissions in Azure Container Registry].